COMMENT ⊗   VALID 00014 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	SPECIAL ISSUE: Many goals
C00006 00003	II.2.b: Goals (page 9)
C00013 00004	III.2: Past (page 12)
C00016 00005	IV.2: Detailed Plans (page 31)
C00019 00006	.SSEC(Designing a System for this task)
C00024 00007	.SSEC(Initial State of AM's Knowledge)
C00028 00008	2. Facets that each concept might have:
C00033 00009	3. Actual initial state: After delineating the concepts which will be given, 
C00039 00010	.SSEC(The Goal: AM running)
C00046 00011	3. A hypothetical dialogue with AM: 
C00053 00012	4. How AM's knowledge interacts to do this:
C00062 00013	5. Estimates of AM's parameters:
C00066 00014	VI. WHY US?
C00067 ENDMK
C⊗;
SPECIAL ISSUE: Many goals

One problem with PUP6 was that it was a big system designed to do one specific
task, to produce one specific program. Thus, even though it "succeeded", it was
hard to measure that success, hard to understand how much the p-u techniques
were successful and how much credit was due to (half-unconsious) hacks.
By the latter, I mean that all the while you are debugging a specific-goaled
system, you know damn well what the goal is. If something goes wrong, you can
just look ahead and see how to patch it up, rather than having to go back to
the root of the difficulty. This is in fact how the PUP6 natural language
system was developed: piecemeal, by adding a new ability whenever needed.
(Completely Heuristic Evaluation And Translation Into New Grammar:
C.H.E.A.T.I.N.G.)

Seriously: One big lesson from PUP6 is: DON'T SET YOUR SIGHTS ON A SPECIFIC
TARGET, NO MATTER HOW GLORIOUS THAT SINGLE TARGET LOOKS!!! 
While PUNS incorporates this by having 18 goals (for this purpose, you
apparently feal 18 is essentially ∞), AM goes all the way and has no idea
what it's doing. Hmmmm.... maybe I'd better reprhrase that...
I consider it an ADVANTAGE that AM has no set goals, no known "final set of
concepts which should have been learned/discovered".

II.2.b: Goals (page 9)

The second system we call ⊗3AM⊗* (⊗3A⊗*utomated ⊗3M⊗*athematician). 
Its design is that of a heterarchical pool of small programs, one for
each mathematical concept in AM's repertoire. Such a program is thus
AM's knowledge about a particular operator, object, or relationship. 
Since concepts will be represented procedurally, adding new knowledge
is equivalent to synthesizing additional programs.  AM's only activity
is to augment its store of knowledge,
which means
writing new little programs to add to itself,
and modifying the existing knowledge programs.

Ideally, AM will engage in what can be honestly regarded as
mathematical  research:
(i) proposing axiomatizations,
based on AM's earlier successes and/or on simulated
real-world situations;
(ii) proposing  and proving conjectures, using the
heuristics discussed by Polya;
(iii) using intuition, by which I
mean employing simulated real-world scenarios to gather empirical evidence;
(iv) evaluating concepts and theories for aesthetic interest;
and (v) using such judgments to guide development in the most promising direction.

More specifically, AM will be initally given ⊗2universal⊗* concepts,
those needed in every field of mathematics. These concepts include:
sets, relations, properties, problems, problem-solving
proof techniques, analogy; abilities
to evaluate interestingness, to locate relevant knowledge.
AM will use its strategies to compound these into new concepts, new little programs.
Hopefully, it will
develop the notion of Cardinality, which paves the way to the domain
of (elementary) number theory. Later, AM may develop enough mathematical systems to
notice a common structure, which will be abstracted into something like the
group axioms. This might then lead into developing elementary abstract algebra.

While this goal sounds quite ambitious,
several simplifications are planned, to make this project feasable:

.BEGIN PREFACE 1 INDENT 2,4,0

(i) Each knowledge program will be small, and constrained to conform to a fixed
schema. This reduces the complexity of the automatic coding task.

(ii) By hand, we must codify and encode programs which give AM the needed ability
to automatically acquire knowledge. 
In addition, one would suppose it necessary to add much specific knowledge about
mathematical constructs.
But this won't be necessary, because
AM will then be able to augment itself automatically.
Only a small amount of detailed knowledge must thus be initially supplied.

(iii) 
Even this can be simplified.
The domain of the synthesized programs is whatever domain of mathematics
is being developed. By choosing the very basic domain of set theory,
we further reduce the amount of domain-specific
expertise that AM must possess initially.

(iv) 
Since AM can develop on its own, the human user need only guide, not teach it.
The basic paradigm for
interacting with AM is: observe its behavior, occasionally interrupt
it and redirect its energies.  
Even when messages ⊗2must⊗* be passed between system and user, the fact that
the domain is elementary mathematics means that 
the language needed to express
those messages can
be fairly simple.
Since the quantity and variety of these
communications are small, the complexity of the communication task is reduced.

.END

We must distinguish the task of the system from the objectives of the research.
We are working on PUNS to learn about understanding programs, %2not%*
because we hope that PUNS will write some super-human concept-formation
program. We are working on AM to see how to apply the techniques of 
program understanding and writing to a particular task not ususally
thought of as program-understanding;
we don't expect   it to produce new mathematical results. 
Each system should, however, provide new insights into how humans write programs
in these domains, and what is required to automate this behavior.
For example, if we strive to include all the obvious judgmental criteria in
AM originally, then when AM first falters we can analyze its difficulty
and learn one nonobvious fact about evaluating interestingness.
III.2: Past (page 12)

PUP2: It was able to construct an integral square-root algorithm,
given the definition of real square-root (but no algorithm for it)
and given an algorithm for addition and for multiplication. 


PUP6:

One reason for the success of PUP2 was structuring all the knowledge
in the system in an accessable manner. In PUP6, written by D. Lenat,
this is carried to the extreme: all knowledge is organized into
clumps called BEINGS, and each BEING is constrained to have the same
internal structure.  A script was simulated by hand, a hypothetical
discussion among 100 cooperating human experts who were given the
task of writing a structural concept formation program.  The
knowledge that each expert used was isolated, categorized, and
embodied in a BEING.  So PUP6, a collection of 100 BEINGs, was able
to reproduce the hypothetical discussion, and in fact did synthesize
the desired concept formation program. With a few additions, PUP6
generated a grammatical inference program and a simple property list
manipulater.  But the BEINGs' knowledge was too specific: the system
as a whole did not properly "understand" programming or inductive
inference.  The dialogues which produced these programs were awkward
and brittle. 

[This is not written in the same style, but it is more natural than
just asserting what PUP6 wrote, which would greatly detract from
the novelty of PUNS -- dbl]

IV.2: Detailed Plans (page 31)

.SSEC(A Model of Math Research)

AM is an attempt to automate mathematical research, by applying the
techniques and the mechanisms of program-understanding systems.
Of course, to automate X, one must have a fairly clear model of how
X is done. Thanks to Polya, Kersher, Hadamard, Skemp, and many others,
such a model can be pieced together. Here, in highly abbreviated form,
is such a model:

1. The order of events in a typical mathematical investigation is:
Observe →→→ Notice Regularity →→→ Formalize →→→ Develop the theory.
The observation is either of reality or an analogous, already-established
mathematical theory.

2. The key to keeping this from becoming a blind, explosive search is the
proper use of evaluation criteria. That is, one must constantly choose the
most interesting, aesthetically pleasing, useful,... concept to expand next.

3. The non-formal criteria (aesthetics, interestingness, intuitive clarity,
utility, analogy, empirical evidence) are much more important than formal
deductive methods in developing mathematically worthwhile theories.

4. The above criteria are virtually the same in all domains of mathematics,
and at all levels. Each factor sometimes encourages investigation in a certain
area, and sometimes discourages further effort.

5. For true understanding, AM must relate to each concept in several ways:
declarative (definition), operational (how to use it), demonic (recognizing
when it is relevant), exemplary (especially boundary examples), and
intuitive (visual image of a real-world interpretation).

6. Progress in ⊗4any⊗* field of math demands much intuition (and some
formal knowledge) of ⊗4many⊗* different mathematical fields. So a broad,
universal core of intuition must be established before any single theory
can meaningfully be developed.

.SSEC(Designing a System for this task)

1. Representation of knowledge in the system: AM will represent each
concept as a bundle of facets (DEFINITION, INTUITION, RECOGNITION,
INTERESTINGNESS,...), and each facet will be stored internally as a
little program.  Each concept will have precisely the same set of
facets.  This enables us to assemble, in advance, a body of knowledge
(called ⊗2strategic⊗* knowledge) about each facet. This is the same
as the BEINGs scheme, a program-understanding representation scheme
used in PUP6. 


2. Control in the system: As AM runs, at each moment, each concept
will have only a few of its facet programs filled in; most of the
facets of most of the concepts will be unknown. AM's only control
structure is to repeatedly choose some facet of some concept, and
then use the appropriate strategic knowledge to fill in that missing
program.  The strategic knowledge will typically access and run many
other facet programs from many other concepts.  In the course of
this, new concepts may be constructed and worth giving names to.
Whenever this happens, the new concept has almost all his facets
blank, which means AM now has about 20 specific tasks to eventually
attend to (if they're deemed interesting enough). So the system never
runs out of things to do; rather, that number keeps growing rapidly. 

3. Program-writing: Recall that each facet is a little program. So
"filling in a facet" means synthesizing a program which meets the
requirements. For facet F of concept C, this requirement is that the
program be able to answer questions about F which might be put to C. 
The know-how to write this program is contained in the strategic
knowledge associated with F. The strategic knowledge is thus also a
program; its "argument" in this case would be C (and implicity, all
the existing concepts), and its "output" would be a little program
which would be filled in as facet F of concept C.  All the techniques
of program-understanding are required to interpret the argument C
meaningfully.  All the techniques of automatic program synthesis are
required to assemble the output program correctly. 

4. AM is interactive: AM informs a human user of the things it finds
which it thinks are interesting.  The user can interrupt AM and
interrogate it, redirect its energies, and so on. Since the user has
several roles, AM should have several languages: traditional math
notation, textbook English, formal (e.g. AUTOMATH or predicate
calculus), pictorial (simulated visual intuitions), etc. 

.SSEC(Initial State of AM's Knowledge)

1. Range of concepts provided: AM will be given strategic information for
each kind of facet that a concept can forseeably have, and will be given
some detailed information about the most universal mathematical concepts.
In the box below, these specific concepts are listed by name:

	<put the given knowl. into a box, please>

.BEGIN FILL SELECT 1 SINGLE SPACE PREFACE 0 TURN OFF "{}-"

.ONCE PREFACE 1
⊗2Objects⊗*

Ordered-pair,
Variable,
Propositional-constant,
Structure,
List-structure,
Bag-structure,
Set-structure,
Assertion,
Axiom

.ONCE PREFACE 1
⊗2Actives⊗*

.INDENT 0,5,0

Operations:  Compose, Insert, Delete, Convert-structure, Substitute, Assign,
Map-structure, 
Undo,
Reverse-ordered-pair, Rule-of-inference, Disjoin, Conjoin, Negate,
Imply, Unite, Set-union, Cross-product, Common-parts, Set-intersection,
Set-difference, Put-in-order, Abstract-out-similarities, Contrast

Relations: Equality, Membership, Containment, Equivalence, 
Equipollence,
Scope, 
Quantification, ⊗1For-all, There-exists, Not-for-all, Never, Only-sometimes⊗*

Properties: Ordered, Extreme, Properties-of-Activities

.ONCE PREFACE 1
⊗2Higher-order Actives⊗*

Find, Select, Guess, Ellipsis, Analogize, Conserve, Approximate

Examine, Test, Assume, Judge,
Define, 
Prove, ⊗1Logically-deduce, Prove-directly, Cases,
Working-backwards, Prove-indirectly, Prove-universal-claims, Mathematical-induction,
Prove-existential-claims, 
Prove-existence-constructively, Prove-existence-deductively,⊗*
Disprove, ⊗1Disprove-constructively, Disprove-indirectly,⊗*

Solve-problem, Debug, Trial-and-error, Hill-climb, Subgoal, Work-indirectly,
Relations-between-problems

Communicate, Communicate-with-user, Translate-into-English-for-User,
Translate-from-English-for-concepts, User-model, Communicate-among-concepts,
Infer-from-examples, Select-representation

Isomorphism, Categoricity, Canonical, Interpretation-of-theory

.ONCE PREFACE 1
⊗2Higher-order Objects⊗*

Statement, Conjecture, ⊗1Statement-of-generality, Statement-of-existence,⊗*
Theorem, Proof, Counterexample, Contradiction, Analogy, Assumption

Problem, Problem-to-find, Problem-to-prove, Problem-to-creatively-define,
Action-problem, Inference-problem, Bug

Representation, Symbolic-representation, Diagram, Scenario

Mathematical-theory, Foundation, Basis, Formal-system

.END

2. Facets that each concept might have:
Each facet program can be viewed as answering a certain family of questions
about the concpet in which it is embedded. For example, the DEFINITION
facet of COMPOSE should be able to tell if any given entity is a composition.
Below is the tentative set of facets that concepts can have, follwed by a
brief description of what question(s) each facet answers:


.BEGIN FILL SELECT 1 PREFACE 0 SPACING 0 INDENT 11,20,0

.ONCE FLUSH LEFT
⊗4RECOGNITION GROUPING⊗*  Notice when this concept, call it B, is relevant.

 CHANGES		Is this rele. to producing the desired change in the world?

 FINAL  		What situations is this concept rele. to bringing about?

 PAST			Where is this used frequently, to advantage?

 IDEN {not}{quick}	{fast} tests to see if this concept is {not} currently referred to


.ONCE FLUSH LEFT
⊗4ALTER-ONESELF GROUPING⊗*  Know about variations of yourself, how good you are, etc.

 GENERALIZATIONS	What is this a special case of? How to make this more general.

 SPECIALIZATIONS	Special cases of this? What new properties exist only there?

 BOUNDARY		What marks the limits of this concept? Why exactly there?

 DOMAIN/RANGE {not} Set of (what one can{'t} apply it to, what kind of thing one {never} gets)

 ORDERING(Complete)	What order should the parts be concentrated on (default)

 WORTH	Aesthetic, efficency, complexity, ubiquity, certainty, analogic utility, survival basis

 INTEREST		What special factors make this type of concept interesting?

 JUSTIFICATION   Why believe this? Formal/intu. For thms and conjecs. What has been tried?

 OPERATIONS  Properties associated with concept. What can one do to it, what happens then?


.ONCE FLUSH LEFT
⊗4ACT-ON-ANOTHER GROUPING⊗*  Look at part of another concept, and perhaps do something to it.

⊗1CHANGE⊗* subgrouping of parts:

 BOUNDARY-OPERATIONS {not}  Ops rele. to patching {messing}up not-bdy-entities {bdy-entities}

 FILLIN  How to initially fill it in, when and how to augment what is there already.

 STRUCTURE 		Whether, When, How to retructure (or split) this part.

 ALGORITHMS		How to compute this, do this activity. Related to Representation.

⊗1INTERPRET⊗* subgrouping of parts:

 CHECK   		How to examine and test out what is already there.

 REPRESENTATION  How should entities of type B be structured internally? Contents' format.

 VIEWS	(e.g., How to view any Active as an operator, function, relation, property, corres., set of tuples)
 


.ONCE FLUSH LEFT
⊗4INFO GROUPING⊗* General information about this concept, B, and how it fits in.

 DEFINITION		Several alternative formal definitions of this concept. Can be axiomatic, recursive.

 INTU		Analogic interp., ties to simpler objects, to reality. Opaque.

 TIES   	Alterns. Parents/offspring. Analogies. Associated thms, conjecs, axioms, specific concept's.

 EXAMPLES {not} {bdy}	Includes trivial, typical, and advanced cases of each type.

 CONTENTS       What is the value stored here, the actual contents of this entity.


.END

3. Actual initial state: After delineating the concepts which will be given, 
and the facets
that a concept might have, there remain two additional knowledge-gathering tasks:
(i) Fill in some of the facets for each of the concepts initially to be supplied,
and (ii) Fill in the strategic information for each facet. For example, the box
below contains the INTERESTINGNESS facet of the concept COMPOSE. That is, it gives
procedures for determining when any specific composition is to viewed as interesting:

<put this in a box, please>

 
   A composition is interesting if any of the following are true:
	The result satisfies some interesting property 
		which is not true of either argument relation.
	Interesting properties of both argument relations are preserved.
	Undesirable properties of both argument relations are lost.
	Interesting subsets (cases) of domain of 1st argument operator map into 
		interesting subsets of range of 2nd argument operator.
	Preimages of interesting subsets (cases) of range of  2nd argument
		are themselves interesting subsets of domain of 1st argument.
	The range of the first argument operator is equal to, not just a subset of,
		 the domain of the second argument operator.



Notice that the first five factors are all recursive, depending on interestingness
of the arguments, properties, etc. The final hint is ⊗2not⊗* recursive; ultimately,
every interstingness "search" terminates at such factors.
An example of ⊗2strategic⊗* information is presented below. For each facet,
several different kinds of strategic information is desirable
(how to fill it in, how to check what's there, how to extend what's there already,
the format of the facet, when to break pieces off and call them new concepts, etc.).
The box below contains the hints for FILLING IN the IDEN facet of any concept:
Recall that a concept C is recognized as mentioned in an expression iff C's
IDEN part responds that C is referred to.

<PUT IN BOX>

   Initially, with low priority: Ask the user how he will refer to C.
	If C gains high interest, then the priority of asking the user increases.
   Find a concept D analogous to C, explicate the analogy, then map over D's IDEN part.
   Find a similar concept D, explicate the differences as a program, run that program
	on D's IDEN part, and insert the results into C's IDEN part.
   Ensure that C is clearly distinguishable from all related other concepts.
   For efficiency, since most recognition tests will fail, put Non-Iden tests at front.
   To write a Non-Iden test, find similar concepts, explicate differences between
	them and C, and make those differences into the test. Thus if the test fails,
	then C might sometimes suggest some related concept which will not fail.
   One entry in IDEN can be assembled as follows: consider a full description of C,
	then delete all but the main words, then append them. If this is too long,
	just use the first syllables. If this is still too long, just use the initials.


Notice the mixture of programming knowledge, naming psychology, analysis of algorithms
strategies, etc.  Below is another bit of strategic knowledge: how to CHECK
the ALGORITHMS facet of a concept:

<PUT IN BOX>

	Ensure that the algorithm can be run on a few randomly selected elements from the domain.
	Ensure that the algorithm can be run on a few boundary examples of C's domain.
	Run the algorithm on a few random candidates from C's domain, and check that
		the I/O pairs do in fact satisfy C's definition.
	Run the algorithm on a few boundary elements of C's domain, and check that
		the I/O pairs do in fact satisfy C's definition.
	
.SSEC(The Goal: AM running)

1. No specific goal: One of the falws of PUP6 was that it had one particular
target. Since PUP6 did synthesize that target, it was never clear precisely
how important various aspects of its design were, and there no "experiments"
one could run on it. By contrast, AM has no set goal, no target "final state"
of knowledge. Its actions are knowledge acquisition, guided by evaluation
criteria and discovery heuristics. It will be a success if it does something
interesting, if it develops some mathematically inteesting concepts (no doubt
ones that are well-known already, like cardinality). This lack of specificity
is considered an advantage, since the system creators can't (even unconsciously)
predetermine what is "necessary" for AM to start with, to acheive a fixed goal.

[this last paragraph perhaps should be rewritten. 
	The first part perhaps goes with PUP6 -- dbl]

2. Some possible developments: To say that AM has no specific goal does not mean
that we can't evaluate its performance, or that we have no idea what it might do.
In fact, below are a list of early numerical concepts, follwed by a brief
explanation of how/why we expect AM to discover them:

<in box>

.BEGIN FILL INDENT 0,4,0

COUNT. This operation converts any list (of length n)
into canonical form (perhaps a list of n NILs). 
It might have evolved from the notion of 1-to-1-correspondence of sets, by
considering  a relation which relates 2 sets iff they are equal in size.
Intuition: a tower of blocks n high, a pile of n marbles.

INVERSE. This is simply the operation MAPSTRUC(REVERSE-ORDERED-PAIR).
That means: view a relation as a set of ordered pairs, then reverse each pair.
Intuitively: Inverse of adding a block or marble is the act of removing one.

COMMUTATIVITY.  This is the condition of being invariant under INVERSE.
R = R↑-↑1.  Intuitively: Seesaw simulation.

TRANSITIVITY.  This is the condition of being invariant under COMPOSITION
with itself.  R*R = R.  Intuitively: relation of higher than, heavier than.

ASSOCIATIVITY.  This is the condition of being invariant under COMPOSITION with
CONVERT-TO-BAG. That is, R takes a multiset as its argument.
Intuitively: the idea of the weight of a pile of marbles.

SINGLETON.  This can be noticed as the property MAP2STRUC(EQUALITY);
that is, a set S is a singleton iff ⊗6∀x,yεS. x=y.⊗*
Intuitively:a lone marble or block.

FUNCTION.  This is noticed as  MAPSTRUC(SINGLETON*IMAGE). That is, the relation
f:A→B turns out to be a function iff the image of each element of A is a singleton.

SUCCESSOR.  This is just the composition COUNT * CONS(NIL,.). In fact, for canonical
lists, SUCCESSOR(L) = CONS(NIL, L).
It corresponds to adding another marble or block. 
Similarly, PREDECESSOR is COUNT*CDR. For numbers, PREDECESSOR coincides with CDR.

ZERO.  This is noticed and worth saving because 
(i) it is COUNT(NIL), where NIL is the
distinguished list,  (ii) it is the only list which has no predecessor,
(iii) It is the initial weight of the empty marbles' scale's pans,
(iv) it is the height of the platform on which we build our blocks towers.

PLUS.	This is just the composition COUNT * APPEND. 
It is the weight of a combined pile of marbles.

TIMES. Once Plus is discovered, it is related to repeated Successor-ing.
This indicates that AM should look at repeated Plus-ing, i.e., multiplication.

ONE. This is distinguished because (i) it is the successor of the distinguished
concept Zero, (ii) it is the identity element of TIMES, (iii) it relates
Successor to Plus, namely Plus(x,1) = Successor(x), (iv) it is the Count of any
singleton, (v) it is the weight of a marble, (vi) the height of a block,
(vii) the COUNT of CAR of any number.

TWO. Distinguished as (i) Successor of One, (ii) Plus(1,1), (iii) Count of any
ordered pair.

.END

3. A hypothetical dialogue with AM: 
Assume that AM has just developed all the
preceding concepts, in addition to its universal store (item * on page *).
Here is how the ensuing dialgoue might appear to the user sitting at a teletype.

.BEGIN SELECT <NGR25> FILL INDENT 0,3,0 TURN OFF "{}-"

SYSTEM: Rate of drop of interest in Repeated TIMES-ing
(compared to SUCCESSOR, PLUS, TIMES) is huge.

USER: (interrupting)  Call this EXPONENTIATION. Why isn't it interesting?

SYSTEM: Not associative or commutative; no Left identity element.
Dissuades me from pursuing higher order constructed operations.

SYSTEM: I am now investigating the inverses of Plus and Times.
In general, the inverses are not functions.  
Do you think they're worth looking at anyway?

USER: Spend a few minutes on it.

SYSTEM: Looking at more examples of TIMES↑-↑1. 
TIMES↑-↑1(n) seems always to include, as one ordered pair,
(n, 1). Same for (1, n). So I can state:
.ONCE PREFACE 0
Conjecture: (∀xεN)  (x,1) ε TIMES↑-↑1(x), and (1,x) ε TIMES↑-↑1(x).
Proof is simple: TIMES(x,1)=x=TIMES(1,x).

SYSTEM: The two pairs (n,1) and (1,n) 
are distinct iff the number n is not equal to 1.
Noticing the number 1 as an exception, we can state:
.ONCE PREFACE 0
Corollary: COUNT*TIMES↑-↑1(1) = 1;  (∀x>1) COUNT*TIMES↑-↑1(x) ≥ 2.
COUNT * TIMES↑-↑1 is the how many ways one may express a number as a product
of an ordered pair of numbers.

SYSTEM: Interesting to consider the subset P of N, 
defined as {xεN | COUNT*TIMES↑-↑1(x)=2}.

USER: (interrupting)  Why is this interesting?

SYSTEM: At the moment, we have the known fact f(x)≥y; try to pin down extreme cases,
those x for which f(x) is precisely equal to y. f is COUNT*TIMES↑-↑1, in the current
case, and y is 2.  Do you have any special names you would like me to refer to
COUNT * TIMES↑-↑1 by? Any special names for the subset P?

USER: Call that composition FAC.
Call the set P, of extreme numbers under FAC, PRIMES.

SYSTEM: Syntactic transformation: "PRIME" is the predicate which means "is in PRIMES".

USER: TIMES may also be viewed as operating on a BAG; 
in this sense, TIMES↑-↑1 would 
return all possible bags (of any length) whose product is the given number. 
We do not allow bags to have <2 members, and we do not allow bags longer than 2
to have any 1's in them.

SYSTEM: In this case, the corollary above just says: COUNT(TIMES↑-↑1(x)) ≥ 1. 
The extremes now are just 1 and PRIMES.   
I want a new name for this new interpretation of TIMES↑-↑1.

USER: Call it FACTORS.

SYSTEM: Conjecture: FACTORS(x) always seems to contain a bag containing only
ones and primes, and only one such bag. 
.ONCE PREFACE 0
Proof of existence is by contradiction,
using the lemma  ¬PRIME(x) → ∃(u,v)εTIMES↑-↑1(x) s.t. 1<u<x, 1<v<x.
.ONCE PREFACE 0
Proof of Uniqueness is by contradiction, using the lemma 
(∀a,bεN, xεPRIMES). x|TIMES(a,b) iff x|a or x|b.

USER: Call this the unique factorization theorem. This is very important.
Consider now the sum of all the divisors of a number.

SYSTEM: PLUS * UNION * TIMES↑-↑1 is being investigated. Seems to range from
a low extreme of Successor(the number) up to a high extreme of almost  
Times(the number, itself). The numbers at the low extreme seem to be the primes.
The numbers near the high extreme may not be worth naming. An intermediate point
is twice the number itself.  I will abbreviate the composition as P*U*T.
That is, those numbers n s.t. Times(2,n)= P*U*T↑-↑1(n).
Another intermediate set of points is PRIMES;
that is, those numbers n s.t. PRIME(P*U*T(n)) holds.
This may lead to the conjecture that P*U*T(N) = PRIMES, where N = {all numbers}.

USER: Call these =2n numbers "Perfect Numbers." Forget the others.
There are not many interesting things to prove involving either idea.

SYSTEM: Going on to new topic, then. I shall
consider comparing TIMES↑-↑1 collections from two numbers.

<this leads to GCD and relative primeness>

.END

4. How AM's knowledge interacts to do this:
To delve into detail, let't consider the interesting step from the user's
declaration to call the function FACTORS, and AM's statement of the unique
factorization theorem.
Recall that the control mechanism is just repeatedly select a concept and a
facet, then work to fill in the program for that facet of that concept.
Below, C.F is the notation used for facet F of concept C.

.BEGIN SELECT ≤ngr25> FILL SINGLE SPACE PREFACE 1 INDENT 0,3,0 TURN OFF "{}-"

i. Choose Concept=FACTORS, Facet=TIES.
Gather relevant algorithms from the facets labelled:
[FACTORS.Ties].Fillin, [FACTORS.Genl-Info].Fillin, [FACTORS.Any-Part].Fillin,
[OPERATION.Ties].Fillin, [OPERATION.Genl-Info].Fillin, [OPERATION.Any-Part].Fillin,
[ACTIVE.Ties].Fillin, [ACTIVE.Genl-Info].Fillin, [ACTIVE.Any-Part].Fillin,
[ANY-concept.Ties].Fillin, [ANY-concept.Genl-Info].Fillin, [ANY-concept.Any-Part].Fillin.

ii. First hint collected says: "Let D be the
known concept representing 
the kind of entity in the
range of FACTORS. Then ask D.INTEREST  how to look for interesting
properties or regularities.  If sparse, ask (generalization↑* D).INTEREST also.
Apply these methods to the output of a typical example of FACTORS.
Check interesting property found, by seeing if it holds
for the other outputs from FACTORS  and ensuring it isn't simply part of the
definition of FACTORS."

iii. Because the output of a call on FACTORS is a ⊗4set⊗* of bags,
we are directed to ask SET.INTEREST for aid
in perceiving interesting things about a particular output,
say the output
{(BAG 3 5 5) (BAG 75) (BAG 5 15) (BAG 3 25)} from the call FACTORS(75).
SET.INTEREST is not very big, so we ask STRUCTURE.INTEREST as well.

iv. STRUCTURE.INTEREST explains that there are three 
distinct ways a structure can be interesting.
First, check whether the structure satisfies any known interesting property of that
type of structure.
If not, check to see whether every element satisfies 
the same interesting property. If not, check to see if ⊗4some⊗* element of the
structure satisfies some very interesting property.
The criteria for interestingness being talked about here is the one specified
by the concept representing the type of the elements. In our present case,
our set is a set of ⊗4bags,⊗* so that
means consult all the hints and factors present under BAG.INTEREST. But this is
also very sparse, hence we recursively turn to 
STRUCTURE.INTEREST for evaluation criteria.

v. After a reasonable time, AM cannot find any interesting property satisfied by the
given output set,
{(BAG 3 5 5) (BAG 75) (BAG 5 15) (BAG 3 25)}.
AM also fails to find any single interesting property satisfied
by all four bags which form the elements of that output set.

vi. Now AM looks at each element in turn, that is, each
bag. First we consider (BAG 75), say. This satisfies the property SINGLETON.
We check with other examples of FACTORS and, sure enough, each one of them
contains, as an element, a bag having the property SINGLETON. Comparing these
singletons to the inputs to FACTORS, we conjecture that 
(BAG x) will always appear in the output set of FACTORS(x).

vii. We go back to looking at the individual bags in FACTORS(75).
This time we
look at (BAG 3 5 5).  Each element ⊗4does⊗* satisfy an interesting property,
namely PRIME. We check against the other examples of FACTORS, and sure enough
each one of them contains an element which is a bag of primes. There doesn't
seem to be any obvious relationship to the input argument, so we merely
conjecture that FACTORS(x) always contains a bag of primes, without saying
which primes or how to compute them. This is one half of the Unique Factorization
Theorem. Notice that this is "rough around the edges", namely for the cases
of factors of zero and one, but these will be caught later by an expert concept
who specializes in checking conjectures just before we start to prove them.


viii. Each element of (BAG 3 5 5) also satisfies the property ODD. But this is quickly
rejected by looking at the example FACTORS(2) = {(BAG 2)}.

ix. We now look at the next individual bag in FACTORS(75), namely (BAG 5 15).
Nothing interesting is found here or in the next case, (BAG 3 25).

x. Before going on to prove some of these conjectures, let's see how AM might
notice the uniqueness aspects of them. AM knows that some elements of FACTORS(x)
satisfy MAPSTRUC(PRIME), but some don't. It wants to find out how to characterize
those which do; namely, those bags of primes from those containing a nonprime.
So AM will temporarily create a new concept, called say PF, defined as
⊗6PF(x) = FACTORS(x) ∩ MAPSTRUC(PRIME, x) = {b | BAG(b) ∧ TIMES(b)=x ∧ 1¬εb ∧
∀zεb. PRIME(z)}⊗*.
Which means: all bags of primes whose TIMES is x; which also means all
factorizations of x into bags containing only primes.

xi. In a manner similar to the above, AM will notice that PF of each number seems to
be a SINGLETON. That is, there is only one bag of primes in the FACTORS(x) collection
for a given x.  How does it do this?
The unique factorization theorem can be
consisely be stated as "PF is a function defined on N".
In such a form, it is not surprising that AM will routinely investigate it.

.END
5. Estimates of AM's parameters:

.BEGIN NOFILL INDENT 0 PREFACE 0 TABS 45,55 TURN ON "\" SELECT 1

     NUMBER\Initially\Ultimately

Number of Families of concepts\  5\  5
Number of concepts per family\ 30\100
Number of Parts per concept\ 25\ 25
Size of each part (lines of LISP)\  5\  7
Number of parts filled in\  8\ 20
Size of avg. concept (LISP lines)\ 40\140
Total number of concepts\150\500
Core used by AM\200K\500K
Time per int. result (cpu min)\ 15\  5
CPU time used (hours)\  0\ 50
Human time used (person-hours)\300\1500
Dissertations completed\  0\  1
System programmed around May of 1975.
First results in June, 1975.
Completion in Winter, 1976.
.END

6. Estimated timetable for AM:

i. Codify the necessary core of initial knowledge (facts and the wisdom to employ them).
%7Reality: See Given Knowledge, as presented in the Second Sketch, 
completed 12/10/74.%*

.BEGIN  TURN ON "{"

ii. Formulate a sufficient set of new ideas, design decisions, and intuitive assumptions
to make the task meaninful and feasable.
%7Reality: firmed up by February 1, 1975.%*

iii. Use these ideas to represent the core knowledge of mathematics collected in (1),
in a concrete, simulated system.
⊗7Reality: the current version of Given Knowledge casts this into the concept-family format.
Hand-simulations done during March, 1975, with this "paper" system.⊗*

iv. Implement a realization of this system as a  computer program.
⊗7Reality: Now under way: {DATE}.⊗*

v. Debug and run the system. Add the natural language abilities gradually, as needed.
⊗7Reality: Scheduled for May to November of 1975.⊗*

.END

vi. Analyze the results obtained from this system, with an eye toward: overall
feasability of automating creative mathematical discovery; adequacy of the initial
core of knowledge; adequacy of the ideas, design decisions, implementation
details, and theoretical assumptions.  Use the results to improve the system;
when "adequate,"  forge ahead as far as possible into as many domains as possible,
then reanalyze. ⊗7Reality: 
the 5↔6 cycle will terminate in the Winter of 1976.⊗*

VI. WHY US?

Because we're there.